Distributed simulation

ABSTRACT

A method and apparatus are presented to facilitate simulation of complex systems on multiple computing devices. Model authors can specify state-related information to be exported for viewing or access by other applications and models. Subsystem models may be written to enable connection with other subsystem models via controlled interfaces, such as by defining state-related information for export and providing for a particular use of data imported from other models to which a subsystem model is connected. In some embodiments, a consistent distributed simulation API enables cross-platform, multi-device simulation of complex systems, wherein the proprietor of each subsystem simulation can keep its implementation secret but accessible to others.

REFERENCE TO RELATED APPLICATION

This application is a continuation of application Ser. No. 09/884,528,filed Jun. 19, 2001, which claims the benefit of U.S. ProvisionalApplication No. 60/212,695, filed Jun. 19, 2000, which are herebyincorporated by reference in their entireties.

This invention was made with Government support under ContractF33615-99-C-2911 awarded by the U.S. Department of Defense. The UnitedStates Government has certain rights in the invention.

BACKGROUND

The present invention relates to computer programs that simulatesystems. More specifically, the present invention relates to simulationsystems using a distributed computer network, wherein subsystems can besimulated independently, the subsystem simulations communicating thevalues of input/output variables to simulate subsystem interaction.Present methods of simulating complex systems suffer from limitations insecurity, interoperability, cross-platform communication, and otherfunctional areas. Many simulation platforms fail to enable distributedsimulation at all, limiting the complexity of systems that can bemodeled as a function of the computing and storage capacity of a singledevice. Simulation of complex systems (those of a tank or aircraft, forexample) in a reasonable time is extremely difficult, if not impossible,using widely available computing systems.

Furthermore, where multiple vendors are responsible for the varioussubsystems of a larger system, security and proprietary concerns mayinhibit or prevent formation of cooperative simulation systemscomprising simulation models of each subsystem provided by each vendor.In some contractual and/or regulatory scenarios, vendors may be forcedagainst their preferences to disclose their simulation models to othervendors or authorities, so that simulations may be conducted of thewhole system.

There is thus a need for further contributions and improvements todistributed simulation technology.

SUMMARY

It is an object of the present invention to provide a novel simulationsystem. Another object is to provide a simulation system in whichvarious subsystem simulations are written in different languages andexecuted by different programs running on different computing devices,yet the subsystem simulations communicate to simulate operation of thecombination of subsystems. Yet another object is to provide a simulationsystem in which various parts of the simulation can be executed usingdifferent integration methods and/or parameters from other parts of thesimulation.

These objects and others are achieved by various forms of the presentinvention. One form of the present invention is a unique distributedsimulation system. Further forms include a system in which a pluralityof processors each executes a separate program to independently simulatea different portion of a physical system. At various points in time, afirst one of the processors communicates messages to a second one of theprocessors to convey information regarding the state of the simulatedsubsystem at a particular point in simulation time. The second processoruses the state-related information from the first processor to executeits model of the second portion of the system. In some embodiments ofthis form, the messages are sent at constant intervals in simulationtime, while in other embodiments messages are sent at constant intervalsin real time. In still other embodiments, the messages are sent atvariable intervals depending on the circumstances, such as a function ofone or more variables, the pattern of change in one or more variables,detected network congestion or delay, or the behavior of the other statevariables (in the first model, second model, another model, or acombination thereof).

In another form of the invention, one program exposes an interfaceassociated with a first model, while a second program exposes aninterface associated with a second model. The first interface permitsaccess by the second program to a program-controlled set ofstate-related information of the first model, while preventing access bythe second model to a substantial portion of the first program or model.In some embodiments of this form, the second program's interface allowsthe first model to access a program-controlled set of state-relatedinformation of the second model, while preventing access by the firstmodel to at least a substantial portion of the second program or model.

In yet another form of the invention, a system monitor applicationprovides control and coordination of subsystem simulations. In someembodiments of this form, each subsystem model allows itself to bestarted, stopped, configured, and/or connected with other models by thesystem monitor application. In other embodiments, a model accepts andserves requests to periodically transmit certain state-relatedinformation to one or more data output applications, which may produceone or more graphs of those values (or of a function of those values).In some of these embodiments, a sequence of values of one or morestate-related variables is broadcast to a plurality of possiblerecipients.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a distributed simulation system.

FIG. 2 is a block diagram of two embodiments of model host computers ina distributed simulation system.

FIG. 3 is a block diagram of a system monitor computer and a model hostcomputer in a distributed simulation system.

FIG. 4 is a flowchart of a distributed simulation.

FIG. 5 is a sample view of an OSCOPE application in a distributedsimulation system.

FIG. 6 is a schematic view of a portion of a distributed simulationsystem including a subnetwork arrangement.

FIGS. 7A-7C are a flowchart of a control message handling loop for usein some distributed simulation systems.

FIG. 8 is a sample view of a control panel application in a distributedsimulation system.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

For the purpose of promoting an understanding of the principles of thepresent invention, reference will now be made to the embodimentillustrated in the drawings and specific language will be used todescribe the same. It will, nevertheless, be understood that nolimitation of the scope of the invention is thereby intended; anyalterations and further modifications of the described or illustratedembodiments, and any further applications of the principles of theinvention as illustrated therein are contemplated as would normallyoccur to one skilled in the art to which the invention relates.

Generally, the distributed simulation system illustrated in FIGS. 1-3provides parallel implementations of various portions or aspects(“subsystems”) of a physical system. In this illustrated embodiment,computer 29 starts, stops, configures, and controls connections andinteractions between a plurality of models 22, 24, 26, 28, running onmodel host computers 23, 25, 27. Each model 22, 24, 26, 28 implements amodel of one or more subsystems and makes that implementation availablefor connection to models of other portions of the system. A consistentexternal communication interface (discussed in further detail below) forvarious hardware and software platforms allows each subsystem to bemodeled on a different simulation platform and/or operating system, andfurther allows different vendors of different subsystems to make modelsof their subsystems available for simulation in combination with therest of the system.

It should be noted that the present description can most easily beunderstood in terms of simulation of a physical system with distinctphysical subsystems. “System” as used herein, however, is not intendedto be limited to a physical arrangement of components. The conceptshould be understood to include the subject of any simulation. Likewise,a “subsystem” as used in the present application is not necessarily aphysically distinct set of components. For example, one independentlymodeled “subsystem” might be the heat transfer aspects of an item, whileanother “subsystem” models the electronic aspects of the item.

The implementation of a model for simulation purposes may be programmedby one or many programmers or organizations of programmers, in the samelanguage as other models in the system, or in a different language.

System 20 will now be discussed in further detail with continuingreference to FIG. 1. Network 21 interconnects computers 23, 25, 27, and29. Models 22, 24, 26, 28, running on those computers as illustratedcollectively model a complete system, by each modeling at least onesubsystem and interacting to communicate the states of the simulatedinterfaces between the subsystems at various intervals in real orvirtual time as will be discussed in further detail below. Otherapplications involved in the distributed simulation system 20 are shownin FIG. 1 in various configurations. A simple model host computer 23runs a single model 22, which is accessible to other models 24, 26, 28and other applications (such as system monitor 31) via network 21.

In many embodiments of the invention, however, resources will beavailable within a single host computer to execute additionalapplications. A common configuration is shown in relation to computer 25of FIG. 1. There, model 24 simulates one or more subsystems, and controlpanel 32 issues start, stop, parameter setting, connection-related, andother commands as will occur to those skilled in the art. OSCOPEapplications 33 and 34 display the values of one or more variables orfunctions of variables of model 24 over time. It has been foundexperimentally that this grouping of applications is a reasonablyeffective use of resources on a single computer. When the resourcesrequired by a model are too great to support the additional applications(for example, if the model were a bottleneck in the simulation system),the other components may be off-loaded from the host computer andexecuted on a “neighboring” computer on a local-area network, forexample.

In some situations, multiple models can be executed on a singlecomputer, as shown in relation to computer 27 in FIG. 1. Computer 27runs models 26 and 28, which are each associated with a control panel(35 and 37, respectively) and OSCOPE (36 and 38, respectively).

System monitor 31 runs on computer 29 and controls parameters of andconnections between models 22, 24, 26, 28. In this exemplary embodiment,while control panels 32, 35, 37 each control and monitor a single model(24, 26, 28, respectively), system monitor 31 is designed to manage thewhole distributed simulation system 20. Also running on computer 29 isOSCOPE 39, which monitors one or more variables or functions ofvariables of model 22, for example.

A “system monitor” application 31 (also discussed in more detail below)running on computer 29 sets parameters of the models, controls theconnections between the models, monitors their functioning, and logsrelevant facts, parameters, and events in the simulation. Severalfunctions of system monitor 31 will be detailed further below.

Certain functional components of computers 23 and 25 will now bediscussed with reference to FIG. 2. Model host computer 23 comprisesprocessor 41, which in one embodiment is a conventional, integratedcircuit microprocessor arrangement, such as one or more PENTIUM III orPENTIUM 4 processors (supplied by INTEL Corporation of Santa Clara,Calif., USA), Athlon processors (supplied by Advanced Micro Devices,Inc., of Sunnyvale, Calif., USA), or PowerPC processors (supplied by theSemiconductor Products Sector of Motorola, Inc., of Austin, Tex., USA).

Storage 43 provides the data storage required by computer 23, includingfor example storage for program, model, log, and other data. Storage 43may include one or more types of solid-state electronic memory, magneticmemory, or optical memory, just to name a few. By way of non-limitingexample, storage 43 may include solid-state electronic Random AccessMemory (RAM), Sequentially Accessible Memory (SAM) (such as theFirst-In, First-Out (FIFO) variety or the Last-In, First-Out (LIFO)variety), Programmable Read-Only Memory (PROM), ElectricallyProgrammable Read-Only Memory (EPROM), or Electrically ErasableProgrammable Read-Only Memory (EEPROM); an optical disc memory (such asa DVD or CD-ROM); a magnetically encoded hard disc, floppy disc, tape,or cartridge media; or a combination of any of these memory types. Also,storage 43 may be volatile, nonvolatile, or a hybrid combination ofvolatile and nonvolatile varieties.

Optional input device(s) 45 may include a keyboard, mouse, track ball,light pen, and/or microphone, to name just a few representativeexamples. Also, optional output device(s) 47 may include one or moremonitors, loudspeakers, printers, and/or other recording devices, againto name just a few representative examples.

Operating system 49 is a general-purpose operating system, such as aWINDOWS operating system (published by Microsoft Corporation of Redmond,Wash., USA) or a MAC OS (published by Apple Computer, Inc., ofCupertino, Calif., USA). Other operating systems may be used withoutundue experimentation by those skilled in the art.

Running on operating system 49 is calculation platform 51, which is ageneral-purpose computation and analysis package such as MATLAB(published by The MathWorks, Inc., of Natick, Mass., USA). Somealternative simulation program and platform configurations are discussedbelow in relation to computers 25 and 27. In the case of computer 23,however, an additional simulation toolbox 52 known as SIMULINK (alsopublished by The MathWorks, Inc.) is included to allow the incorporationof the distributed simulation API for the subsystem model implementation22. Model 22 is, in this example, written in the MATLAB programminglanguage with references to procedures and/or objects defined in theSIMULINK toolbox 52 and the distributed simulation interface 55.Interface 55 provides an API comprising functions that enable model 22to programmatically control connections from other computing devices andto process data exchanged through them, as discussed further herein.

Computer 25 is controlled by processor 61 using programs stored instorage 63 (where processor 61 and storage 63 may be of any suitabletype, as discussed above in relation to processor 41 and storage 43,respectively). Optional output device(s) 67 and optional input device(s)65 again facilitate interaction with human users. Operating system 69is, in this example, a WINDOWS 2000 operating system, published byMicrosoft Corporation. Model 24 executes on OS 69 as a stand-aloneapplication written in one or more system programming languages, such asC, C++, Fortran, Visual Basic, or JAVA.

Browser 71 enables access to and viewing of resources available throughnetwork 21, such as Hypertext Markup Language (HTML) files and JAVAapplets (such as system control applet 32). Browser 71 may be, forexample, Netscape Navigator (published by Sun Microsystems, Inc., ofPalo Alto, Calif., USA). OSCOPE applications 33 and 34 readstate-related information from model 24 and send it as output to theuser via output device(s) 67. Like interface 55, distributed simulationinterface 75 provides communication-related functionality to model 24.

FIG. 3 shows the components of computers 27 and 29 (see also FIG. 1). Incomputer 27, storage 83, optional input device(s) 85, and optionaloutput device(s) 87 are analogous to (though not necessarily the sameas) 43, 45, and 47. Here, again, subsystem model implementations 26, 28are stand-alone applications written in one or more system programminglanguages, such as C, C++, Fortran, Visual Basic, or JAVA, to name justa few nonlimiting examples. Processor 81 is a custom-designed,application-specific integrated circuit (ASIC) specially adapted forsimulation computations. A custom-designed simulation operating system89 runs subsystem model implementations 26 and 28, which communicatewith each other and with other models in system 20 via distributedsimulation interface 88. Control panel application 35 and OSCOPEapplication 36 connect to model 26 and run on simulation operatingsystem 89, which also runs control panel 37 and OSCOPE 38 in conjunctionwith model 28. System monitor application 31 runs on operating system 99to provide command and control functionality for system 20 as summarizedabove and discussed in more detail below. OSCOPE application 39 alsoruns on operating system 99, displaying to the user at computer 29 anoutput of state-related information from model 22 on computer 23 (seeFIG. 1).

Computer 29 includes processor 91, storage 93, input device(s) 95, andoutput device(s) 97 (analogous to, but not necessarily the same as,corresponding components in computer 23; namely, components 41, 43, 45,and 47). Operating system 99 is, for example, a UNIX or UNIX-likeoperating system such as Red Hat Linux (published by Red Hat, Inc., ofDurham, N.C., USA).

While the above description relating to FIGS. 1-3 illustrates severaluses and arrangements of computing resources, and several illustrationsof connections and relationships among components, applications,applets, models, and other physical and functional parts of system 20,it should be noted that those skilled in the art will be able toimplement distributed simulation systems according to the presentinvention with these or other physical and/or virtual configurations.For example, any functionality described herein can be implemented inany computing device in communication with at least one other componentin the system.

The process for carrying out a simulation according to one embodiment ofthe present invention will now be discussed in broad terms in relationto FIG. 4, with continuing reference to items shown in and discussed inrelation to FIGS. 1-3. Additional detail regarding the control ofconnections among models in a selected embodiment of the presentinvention will be discussed below in relation to FIGS. 7A-7C. Theprocess 100 in FIG. 4 starts at START point 101. The various models arestarted at block 110. In various embodiments, this event may beinitiated for each model by an action of a local user (such as a gesturein a desktop graphical user interface (GUI)), by a remote user (forexample, through a web browser or by way of another signal), or by anautomated process (such as invocation by a task scheduler), to name justa few possible triggers. In some of these embodiments, the operatingsystem 49, 69, 89, 99, calculation platform 51, simulation toolbox 52,subsystem model implementations 22, 24, 26, 28, and distributedsimulation interface software 55, 75, 88 are loaded into memory andinitialized with simulation parameters as will be understood by thoseskilled in the art.

At block 120, parameters (such as capacitance of a capacitor, or densityof fuel in the system being simulated) for the various models 22, 24,26, 28 are set, for example, by the system monitor application 31 or thecontrol panel 32, 35, 37 associated with each particular model. Invarious embodiments, these parameters may be provided by a localconfiguration file, user input, a signal from system monitor 31 or acontrol panel, or other source as would occur to one skilled in the art.

Models may be connected to and/or disconnected from other models atblock 130, again under the control of system monitor 31 or the model'srespective control panel 32, 35, 37. For example, in some embodimentsthat use the TCP/IP protocol stack, IP addresses and TCP port numbersare obtained (e.g., from local storage 43, 63, 83, one or more commandline parameters, system monitor 31, etc.), and TCP connections areopened.

Connected models exchange control and state-related information at block140 and export state-related information to an OSCOPE or othermonitoring process at block 150. In the example embodiment shown inFIGS. 1-3, subsystem model implementation 24 receives state-relatedmessages from subsystem model implementation 22 that communicateinformation relating to one or more state variables from subsystem modelimplementation 22. Subsystem model implementation 24 then uses thatinformation in its simulation. For example, subsystem modelimplementation 24 will, in some implementations, use the informationfrom the state-related messages as an input to the subsystem beingsimulated. In some of these embodiments, state-related messages fromsubsystem model implementation 24 to subsystem model implementation 22provide information relating to one or more state variables in subsystemmodel implementation 24 as input(s) to the operation of subsystem modelimplementation 22.

Other commands are processed by the models at block 160, and it isdetermined at decision block 170 whether the system 20 should continueoperation. If so, process 100 returns to the beginning of the commandprocessing loop at block 120. If system 20 is not to continue operation(negative result) at decision block 170, the process 100 is ended at ENDpoint 199.

While process 100 is illustrated in FIG. 4 as a linear, single-threadedtask, it may be implemented in a multi-threaded form, on multiplecomputing devices, or with an alternative control flow, as would occurto one skilled in the art.

In this exemplary embodiment, distributed simulation interfaces 55, 75,88 expose an application programming interface (API) for development ofthe various subsystem model implementations 22, 24, 26, 28. Thefunctions in this API, the ACSL version of which is shown below in Table1, allow the subsystem model implementation programmer to control thevariables that are imported from and exported to other subsystemsimulations.

TABLE 1 Function Arguments Description COM_INIT (MIN) MIN—model indexnumber Initialize a model for distributed processing. ADD_PORT (name,desc., name—string name for the Declares a channel to be used status)port for input and/or output desc—string that provides avariables/messages. description status—connection status variableADD_PORT_VAR_IN (PIN, PIN—port index number Associates an input variablevar) var—variable name for input with a port. from port ADD_PORT_VAR_OUTPIN—port index number Associates an output variable (PIN, var)var—variable name for output with a port. to port ADD_PARAM (name,value) name—parameter name Declares a simulation variable value—initialvalue that can be set by system monitor 31 and/or control panel 32, 35,37 when this subsystem simulation is initialized or started. A defaultvalue is provided. OSCOPE (OIN, t_interval, OIN—oscope index numberDefines a set of variables for var1, . . . , varN)t_interval—communication export to an OSCOPE interval application andthe var1, . . . , varN—variable (simulation) time interval names betweensamples. EXCHANGE (PIN, t_interval) PIN—port index number Sets the rateof data exchange t_interval—communication for a given port. intervalCOM_LISTEN (t_interval) t_interval—communication Defines the frequencywith interval which the model will check for new control panel, systemmonitor, and remote model data connections. COM_CLOSE No Arguments Stopsthe model from listening for connections and exchanging data; freescomputing resources allocated to inter-model communication.In this exemplary embodiment, port index numbers (PINs) and OSCOPE indexnumbers (OINs) are sequentially assigned, beginning with zero, each timethe ADD_PORT or OSCOPE functions, respectively, are called. Then, whenan OSCOPE requests a connection to a particular model, the modelconnects the requesting application (or applet) to the next availableOSCOPE index number, if another exists.

Thus, in the illustrated embodiment, the interval between exchanges ofdata is set by the programmer of the model using the commands shown inTable 1 before the simulation is executed. Exchanges for a given portoccur at regular intervals (which may be the same as or different fromthe intervals used for other ports) in simulation time, using the modeltime as a frame of reference. In some alternative embodiments, areal-time or other external frame of reference is used, while in otherembodiments, the intervals are dynamically controlled as discussedherein.

The functions shown in Table 1 are provided in various forms toaccommodate the various simulation environments that may be availablewithin system 20. For example, the functions may be implemented in adynamically linked library (.DLL), source code library, device driver,operating system API or other format as would occur to one skilled inthe art and be acceptable given the constraints of its implementationenvironment.

A message-handling loop for processing simulation control messagesappears in FIGS. 7A-7C. This example may easily be modified by thoseskilled in the art to include additional message processing tasks orother events that may occur in a given implementation of the invention.Furthermore, non-message-based control mechanisms may be used in variousembodiments of the invention.

A message handling loop 300 for a given model will now be described inrelation to FIGS. 7A-7C. To summarize, loop 300 begins at START point301, handles system monitor connection activity in part 310, handlescontrol panel activity in part 320, handles commands from the controlpanel in part 330, handles incoming model connection requests in part350, handles incoming OSCOPE connection activity in part 360, handlessystem monitor commands in part 370, and ends at END point 399.

In part 310 of loop 300, the model confirms at block 312 that it islistening for incoming connection requests from system monitor programs.If it is determined at decision block 314 that a system monitorconnection request is pending (positive result), then at block 316 thesystem monitor attempting to connect is established as the active systemmonitor for the local model(s). Then, or if no such connection ispending (negative result at decision block 314), processing in part 310ends and loop 300 proceeds to part 320.

Loop 300 handles incoming control panel connection activity in part 320by first confirming in block 321 that the system is listening forincoming control panel connections. If it is determined at decisionblock 323 that an incoming connection is pending from a control panelapplication (positive result), the control panel application isestablished at block 325 as the active control panel. Current parameterand port information for the local model is then sent to that controlpanel at block 327, and if a system monitor is active, it is notified ofthe new connection at block 329. At that point, or if it is determinedat block 323 that no connection from an external control panel iswaiting (negative result), loop 300 proceeds beyond part 320 into part330.

Loop 300 handles any pending control panel commands at part 330. It isdetermined at decision block 331 whether a control panel is currentlyconnected to the local model. If not (negative result), loop 300proceeds beyond part 330 (via placeholder A) to part 350. If it isdetermined that a control panel is connected (positive result atdecision block 331), it is determined at decision block 333 whether acommand from that control panel is waiting. If not (negative result atdecision block 333), loop 300 proceeds to part 350 (via placeholder A).

If it is determined at decision block 333 that a command is waiting(positive result), the command is read at block 335, and the relevantparameter name and value for a “set parameter” are read at block 337.The given parameter is updated to reflect the new value at block 339,and if a system monitor is connected, it is notified at block 341 of theupdate.

Decision block 343 implements an optional method forconnecting/disconnecting remote models via control panel commands. Ifthe parameter read at block 337 is not a valid port index number (“X”result at decision block 343), loop 300 proceeds to part 350 (viaplaceholder A). If the parameter name is a valid and the correspondingport status value is not one (negative result at decision block 343),the connection through that port is closed at block 345, and loop 300proceeds to part 350 (via placeholder A).

If the port status value is one (positive result at decision block 343),model connection parameters (including, for example, the IP number ofthe remote model host, the remote model index number, the remote portindex number, and the local model index number) are read from thecontrol panel at block 347. A connection between the identified localmodel and the identified remote model is then initiated at block 349,and loop 300 continues with part 350.

Loop 300 processes incoming connection requests from other models inpart 350. At block 351, it is confirmed that the server is listening formodel connection requests. If such a request is not waiting (negativeresult at decision block 353), loop 300 proceeds to part 360. If a modelconnection request is waiting (positive result at decision block 353),the requested PIN is read at block 355, and a connection to the remotemodel is finalized at block 357. The internal port status is thenupdated at block 359, and loop 300 proceeds to part 360.

In part 360, loop 300 handles incoming requests for connections fromOSCOPE applications or applets. First, it is confirmed at block 361 thatthe model is listening for such connections. Then, if no OSCOPEconnection request is waiting (negative result at decision block 363),loop 300 proceeds to part 370. If such a request is waiting (positiveresult at decision block 363), the next available OSCOPE identifier isdetermined at block 365, and the metadata (the number of variablesavailable via the requested port, the names of those variables, and thename of the model, for example) for that OSCOPE identifier is sent tothe OSCOPE application or applet at block 367. At block 369, the activesystem monitor (if one is connected) is notified of the activity. Loop300 continues with part 370.

Commands from the system monitor (if one is connected) are processed inpart 370 of loop 300. First, it is checked at block 371 whether a systemmonitor is, indeed, connected. If not (negative result), loop 300 endsat END point 399. If a system monitor is connected (positive result atdecision block 371), it is determined at decision block 373 whether acommand from that system monitor is waiting to be processed. If nosystem monitor command is waiting (negative result at decision block373), loop 300 terminates at END point 399. If a command is waiting(positive result at decision block 373), loop 300 proceeds (viaplaceholder B) to part 400, shown in FIG. 7C. When processing in part400 is complete, loop 300 reaches END point 399 and terminates, orrepeats by beginning again at START point 301.

At block 401 in loop 400 shown in FIG. 7C, the requested command is readfrom the system monitor. At decision block 411, it is determined whetherthe system monitor is requesting display of parameter and/or port data.If so, the name of the item being requested is read at block 413. Ifthat name is “PARAMS” or “ALL” (positive result decision block 415), thenames and corresponding values of each parameter of the model are sentat block 417 to the system monitor. Then (or upon a negative result atdecision block 415) it is determined at decision block 419 whether thename that was read at block 413 is “PORTS” or “ALL.” If so (positiveresult at decision block 419), the name and status of each port of themodel are sent to the system monitor at block 421. If, however, theresult at decision block 419 is negative, the name and value of thespecified (at block 413) parameter are sent to the system monitor atblock 423. After the actions of either block 421 or 423, loop 300returns (via placeholder C) to the END point 399.

If the command read at block 401 is not a request for display of one ormore parameters (i.e., a negative result at block 411), it is determinedat decision block 431 whether the command is for the registration of amodel. If so, the model name is read at block 433 and the model isregistered at block 435. Loop 300 then returns (via placeholder C) toEND point 399.

If the command read at block 401 is also not for registration of a model(negative result at decision block 431), it is determined at decisionblock 441 whether the command was a request to set a parameter value. Ifso (positive result), the name and new value are read at block 443, andthe value of the specified parameter is updated at block 445. Then, forlogging, debugging, or other purposes, the names and values of allparameters and ports are sent to the control panel at block 447. Loop300 then returns (via placeholder C) to END point 399.

If the command read at block 401 is also not a request to set a modelparameter (negative result at decision block 441), it is determined atdecision block 451 whether the command is a request to connect a localmodel to a remote model. If so (positive result), the parameters forestablishing that connection (see above discussion in relation to block347) are read at block 453. The requested connection between the remotemodel and the local model is then initiated and established at block455. Loop 300 continues at block 447 by sending the values and status ofthe parameters and ports to the control panel as discussed above, andreturns (via placeholder C) to END point 399.

If the command read at block 401 is not a request to connect a model(negative result at decision block 451), it is determined at block 461whether the command is to disconnect a model. If so (positive result),the port to disconnect is read at block 463. It is then determined atdecision block 465 whether all ports have been requested to bedisconnected. If so (positive result), all ports are closed at block 467and loop 300 proceeds with a report to the control panel of parameterand port information at block 447, discussed above. If a specific portwas requested to be closed (negative result at decision block 465), thatspecific port is closed at block 469, and loop 300 continues with thereport of parameter and port information at block 447, discussed above.

If the command read at block 401 is determined at decision block 461 notto be a disconnect request, the command is ignored, and loop 300proceeds (via placeholder C) to END point 399. It should be noted thatvarious embodiments of the present invention may process different,additional, or fewer commands than those discussed in relation to part400, as would be understood by those skilled in the art. It should alsobe noted that those skilled in the art will understand other commands tobe available via the control panel other than the “set parameter”command described in relation to FIGS. 7A-7C.

It may also be observed that loop 300 illustrates the simultaneousconnection of at most one system monitor and one control panel to agiven model. While some embodiments of the present invention may operatewith both types of control applications being connected, others mayprevent the simultaneous connection of both types of controlapplications, and others may require both to be connected for certainfunctionality. Still others may allow multiple instances of one or bothtypes of control applications to a given model.

It should also be noted that the discussion of loop 300 has beensimplified for easier understanding by omitting details relating tocommunication protocols being used, acknowledgements being sent and/orexpected, and error handling. For example, it is preferred that model,port, OSCOPE, and other identification numbers and handles be validatedby distributed simulation interfaces 55, 75, 88 before they are used. Insome embodiments, errors are ignored, while in other embodiments, theycause a log entry to be created, alarm to be set off, and/or the systemhalted.

An exemplary embodiment of an OSCOPE application according to one formof the present invention will now be discussed with reference to FIG. 5.The OSCOPE application facilitates access to particular state-relatedinformation of the various models 22, 24, 26, 28 of system 20. Agraphical user interface (GUI) 200, comprising control elements 202,output formatting elements 204, and graph elements 206, facilitates userinteraction with the OSCOPE application. Control elements 202 accept theuser's selection of a model host (IP address), model index number (MIN),and output format for the display. When the user selects the “connect”check box, the OSCOPE application attempts to connect to the selectedmodel.

As the simulation data is received from the selected model, it isdisplayed in output graphs 206. Various user interface components 204allow the user to select a wide variety of formats for display,including selecting the variable to graph, scaling the graph in one ormore dimensions, automatically scaling the graph using the ranges ofdata points acquired, displaying repeated traces based on one or moretrigger points in one or more signals being graphed, connecting thesample points in the display, and/or transforming the signal through aFFT (fast Fourier transform) to name just a few nonlimiting examples. Inthis illustration, the output is graphed in graphs 206, which can besaved on any appropriate medium in any appropriate format, including forexample a graphics file on a magnetic disk. It will be understood bythose skilled in the art that alternative selection, control, and outputforms and techniques may be used as required or desired in a particularembodiment. For example, signal data may be printed in the form of apage, plot, or strip chart by a printer that comprises an “outputdevice” 67 in FIG. 2.

A GUI for use with system 20 is illustrated in FIG. 8. Check box 221establishes or breaks a connection with a particular model based on userinput. Model information area 223 reflects the values of the connectedmodel's parameters and the status of the model's ports. The “parameter”and “value” fields can be used to change the parameters of the model towhich the control panel is connected, while the “Local I/O Port” and“Port Status” elements can be used to connect/disconnect models to/fromthe model being controlled. When it is desired to connect to a remotemodel, the IP address, port identification number, and modelidentification number are entered in area 225 of GUI 220. In thisembodiment, each time the user desires to submit information to themodel, the “submit” button 227 is selected, and the information istransmitted to the model using methods, techniques and protocols knownin the art. Messages received from the connected model as well as anyerror messages are shown to the user in text box 229.

As will be apparent to those skilled in the art, traditional and/oralternative components may exist in or be attached to any of thecomputing devices discussed in this description. Similarly, the networksshown may also connect devices not shown herein, including but notlimited to devices that have no role in the distributed simulation.

In one alternative embodiment of the invention, subsystem modelimplementations 22, 24, 26, 28 are dynamically connected and configuredwhile the model is being executed. In some cases, this dynamicconnection simulates physical connection or reconnection of the physicalcomponents being modeled in the respective implementations.

In another alternative embodiment, a plurality of simulation programstogether simulate a system, each simulation program simulating adifferent subsystem of the system. In yet another embodiment, differentpersons specify the parameters and data of the various subsystem modelsthat can be viewed and/or controlled by or through other computers inthe network.

A portion of still another embodiment is shown in FIG. 6. A plurality ofcomputers 251 form a subnetwork 261 in communication with network 21.Each computer 251 models part of a subsystem, while a gateway computer251 a in the subnetwork 261 serves as a communication gateway forstate-related messages sent between the computers in the subnetwork 261and the rest of the network 21. Gateway computer 251 a may or may notalso host one or more models. In some embodiments of this configuration,the simulations taking place on the non-gateway computers 251 occurindependently (i.e., without reliance on state information from anyother model). In these cases, gateway computer 251 a collects theresults of those subsystem simulations, and may aggregate them or passalong the raw data to other models or other components in system 20.

In another form of the present invention, a plurality of interrelatedsimulation programs are executed on a plurality of computers in anetwork. The plurality of interrelated simulation programs operate inparallel and exchange data with each other. In some embodiments of thisform, the various simulation programs are each executed on the samesoftware package (such as ACSL (published by The Aegis TechnologiesGroup, Inc., of Huntsville, Ala., U.S.A.), Saber (published by Avant!Corporation of Fremont, Calif., U.S.A.), MATLAB/SIMULINK, or EASY 5(published by The Boeing Company of Chicago, Ill., U.S.A.)). In otherembodiments of this form, the various subsystem simulations are executedby a heterogeneous group of software packages (such as an ACSL model onone computer and two MATLAB/SIMULINK models, each on another separatecomputer).

In one embodiment of this form, the plurality of simulation programstogether simulate a real system, wherein each simulation programsimulates a different real subsystem of the real system. In anotherembodiment of this form, different persons specify the parameters anddata of the various simulation programs that can be viewed and/orcontrolled by or through other computers in the system 20.

In another form of the present invention, a computer-readable medium isencoded with programming instructions executable by a first processor to(a) implement a first simulation model having a first state variable,(b) accept a first command signal from a program being executed byanother processor, and (c) manage the first simulation model based onthe first command signal; likewise, second computer-readable medium isencoded with programming instructions executable by a second processorin communication with an output device to (1) send the first commandsignal to the first processor, (2) cause the output device to make afirst output reflecting information relating to the first state variableover a period of simulation time. In one embodiment of this form of theinvention, information relating to the value of one or more statevariables in the first simulation are passed to (or received from) thesecond simulation at regular intervals of real time. In anotherembodiment of this form, information relating to the values of one ormore state variables in the first simulation are passed to (or receivedfrom) the second simulation at regular intervals of simulation time. Inyet another embodiment of this form, information relating to the valuesof one or more state variables in the first simulation are passed to (orreceived from) the second simulation at intervals of simulation timethat vary according to the state(s) of one or more models in the system.In still another embodiment of this form, information relating to thevalues of two or more state variables in the first simulation are passedto (or received from) the second simulation. In a further embodiment,information relating to the values of four or more state variables inthe first simulation are passed to (or received from) the secondsimulation. In a still further embodiment of this form, informationrelating to the values of n≧2 state variables in the first simulationare passed to (or received from) the second simulation, and at least onemessage in a series of state-related messages sent by the firstsimulation contains information relating to the value of each of the n≧2state variables. In a yet further embodiment, information relating tothe values of n≧2 state variables in the first simulation are passed to(or received from) the second simulation, and at least one message in aseries of state-related messages sent by the first simulation containsinformation relating to the value of exactly one of the n statevariables. In other embodiments of this form, one process makes therequest, but the first simulation directs the series of state-relatedmessages to a different process. In yet another embodiment, a processreceives the series of state-related messages and displays (e.g., agraph of a function of a state variable versus [simulation] time) on anoutput device (e.g., a monitor or printer) information carried by aplurality of the messages in that series.

Yet another form of the present invention comprises a plurality ofsimulations operating on a plurality of computers. A system monitorcommunicates with each simulation, and is capable of configuring,controlling, and/or coordinating each simulation. In one embodiment ofthis form, a local control panel applet is also provided for eachsimulation and is capable of configuring, controlling, and/orcoordinating that particular simulation.

In some embodiments, different subsystem model implementations 22, 24,26, 28 use different techniques and/or parameters for integration. Forexample, one model might use the finite Euler integration technique withnew values being estimated every millisecond, while another usesRunge-Kutta integration with a one microsecond estimation interval. Thistype of embodiment enables more efficient simulation of systems thatinclude fast-changing and slow-changing signals by “sampling” eachsubsystem at an appropriate rate without wasting computing resources onfrequent sampling of slow-changing signals.

In some embodiments, plug-in components are provided for simulationdevelopment, wherein a “black box” element is placed in a subsystemmodel implementation design to represent one or more other subsystems inthe simulation. Parameters are programmed for the “black box” thatdefine the inputs and outputs of the subsystem that will be provided byand to (respectively) the neighboring subsystem. In some of theseembodiments, the “black box” is represented by a block in a GUIsimulation design tool. Fields associated with the “black box” in thesubsystem model implementation indicate the networking (e.g., IP addressand TCP port number) and signaling (e.g., messaging frequency andavailability of variables) parameters for that connection.

It will be understood by those skilled in the art that computers 23, 25,27, 29, and other computers discussed in this description may compriseadditional or alternative components as needed or desired in aparticular implementation. Likewise, additional or alternative devicesmay be connected to network 21 and or subnetwork 261 (see FIGS. 1 and 6)without departing from the spirit of this invention.

All publications, prior applications, and other documents cited hereinare hereby incorporated by reference in their entirety as if each hadbeen individually incorporated by reference and fully set forth.

While the invention has been illustrated and described in detail in thedrawings and foregoing description, the same is to be considered asillustrative and not restrictive in character, it being understood thatonly the preferred embodiments have been shown and described and thatall changes and modifications that would occur to one skilled in therelevant art are desired to be protected.

1. A computer-implemented method for simulating operation of a physicalsystem having a plurality of physical subsystems, comprising: simulatinga first physical subsystem with a first continuous-time simulation on afirst physical computing device; accepting a request for export ofinformation relating to a number n of state-related variables thatcharacterize the state of the first physical subsystem in saidsimulating; sending a first series of state-related messages, eachmessage containing information relating to the value of at least one ofthe n state-related variables; simulating a second physical subsystemwith a second continuous-time simulation on a second physical computingdevice; receiving in said second continuous-time simulation said firstseries of state-related messages from said first continuous-timesimulation without said first series of state-related messages passingthrough a central communication process; outputing data representativeof a state of the second continuous-time simulation; wherein: the firstphysical subsystem interacts with the second physical subsystem; the atleast one state-related variable characterizes at least a portion of theinteraction between the first physical subsystem and the second physicalsubsystem; and the number n is at least two; and sending a third seriesof state-related numerical values, wherein: at least one numerical valuein the first series of state-related numerical values containsinformation relating to the values of a first proper subset of the setcontaining all n state-related variables; at least one numerical valuein the third series of state-related numerical values containsinformation relating to the values of a second proper subset of the setcontaining all n state variables, and the second proper subset isdifferent from the first proper subset; wherein: the messages in thefirst series of state-related numerical values are sampled at a firstrate in simulation time in the first simulation; the numerical values inthe third series of state-related numerical values are sampled at asecond rate in simulation time in the first simulation; and the firstrate and the second rate are not equal.
 2. A computer-implemented methodfor simulating operation of a physical system having a plurality ofphysical subsystems, comprising: simulating a first physical subsystemwith a first continuous-time simulation on a first physical computingdevice; accepting a request for export of information relating to anumber n of state-related variables that characterize the state of thefirst physical subsystem in said simulating; sending a first series ofstate-related messages, each message containing information relating tothe value of at least one of the n state-related variables; simulating asecond physical subsystem with a second continuous-time simulation on asecond physical computing device; receiving in said secondcontinuous-time simulation said first series of state-related messagesfrom said first continuous-time simulation without said first series ofstate-related messages passing through a central communication process;outputing data representative of a state of the second continuous-timesimulation; wherein: the first physical subsystem interacts with thesecond physical subsystem; the at least one state-related variablecharacterizes at least a portion of the interaction between the firstphysical subsystem and the second physical subsystem; and the number nis at least two; and sending a third series of state-related numericalvalues, wherein: at least one numerical value in the first series ofstate-related numerical values contains information relating to thevalues of a first proper subset of the set containing all nstate-related variables; at least one numerical value in the thirdseries of state-related numerical values contains information relatingto the values of a second proper subset of the set containing all nstate variables, and the second proper subset is different from thefirst proper subset; wherein: the numerical values in the first seriesof state-related numerical values are sampled at a first rate insimulation time in the first simulation; the numerical values in thethird series of state-related numerical values are sampled at a secondrate in simulation time in the first simulation; and the first rate andthe second rate are equal.
 3. A computer-implemented method forsimulating operation of a physical system having a plurality of physicalsubsystems, comprising: simulating a first physical subsystem with afirst continuous-time simulation on a first physical computing device;accepting a request for export of information relating to a number n ofstate-related variables that characterize the state of the firstphysical subsystem in said simulating; sending a first series ofstate-related messages, each message containing information relating tothe value of at least one of the n state-related variables; simulating asecond physical subsystem with a second continuous-time simulation on asecond physical computing device; receiving in said secondcontinuous-time simulation said first series of state-related messagesfrom said first continuous-time simulation without said first series ofstate-related messages passing through a central communication process;outputing data representative of a state of the second continuous-timesimulation; wherein: the first physical subsystem interacts with thesecond physical subsystem; and the at least one state-related variablecharacterizes at least a portion of the interaction between the firstphysical subsystem and the second physical subsystem; receiving thefirst series of state-related numerical values in a first output processin communication with a first output device; and sending to the firstoutput device a first set of information carried by a plurality ofnumerical values in the first series of state-related numerical values;wherein the first output device is in communication with the firstoutput process; wherein said displaying comprises graphing a function ofthe first state-related variable versus an independent variable; whereinthe independent variable is time.
 4. A computer-implemented method forsimulating operation of a physical system having a plurality of physicalsubsystems, comprising: simulating a first physical subsystem with afirst continuous-time simulation on a first physical computing device;accepting a request for export of information relating to a number n ofstate-related variables that characterize the state of the firstphysical subsystem in said simulating; sending a first series ofstate-related messages, each message containing information relating tothe value of at least one of the n state-related variables; simulating asecond physical subsystem with a second continuous-time simulation on asecond physical computing device; receiving in said secondcontinuous-time simulation said first series of state-related messagesfrom said first continuous-time simulation without said first series ofstate-related messages passing through a central communication process;outputing data representative of a state of the second continuous-timesimulation; wherein: the first physical subsystem interacts with thesecond physical subsystem; and the at least one state-related variablecharacterizes at least a portion of the interaction between the firstphysical subsystem and the second physical subsystem; receiving thefirst series of state-related numerical values in a first output processin communication with a first output device; and sending to the firstoutput device a first set of information carried by a plurality ofnumerical values in the first series of state-related numerical values;wherein the first output device is in communication with the firstoutput process; wherein said displaying comprises graphing a function ofthe first state-related variable versus an independent variable; whereinthe independent variable is one of the n state-related variables.
 5. Acomputer-implemented method for simulating operation of a physicalsystem having a plurality of physical subsystems, comprising: simulatinga first physical subsystem with a first continuous-time simulation on afirst physical computing device; accepting a request for export ofinformation relating to a number n of state-related variables thatcharacterize the state of the first physical subsystem in saidsimulating; sending a first series of state-related messages, eachmessage containing information relating to the value of at least one ofthe n state-related variables; simulating a second physical subsystemwith a second continuous-time simulation on a second physical computingdevice; receiving in said second continuous-time simulation said firstseries of state-related messages from said first continuous-timesimulation without said first series of state-related messages passingthrough a central communication process; outputing data representativeof a state of the second continuous-time simulation; wherein: the firstphysical subsystem interacts with the second physical subsystem; and theat least one state-related variable characterizes at least a portion ofthe interaction between the first physical subsystem and the secondphysical subsystem; receiving the first series of state-relatednumerical values in a first output process in communication with a firstoutput device; and sending to the first output device a first set ofinformation carried by a plurality of numerical values in the firstseries of state-related numerical values; wherein the first outputdevice is in communication with the first output process; wherein saiddisplaying comprises graphing a function of the first state-relatedvariable versus an independent variable; wherein the independentvariable is a state-related variable in the simulation of the secondphysical subsystem.